\documentclass{article}

\usepackage[top=2.5cm, bottom=2.5cm, left=2cm, right=2cm]{geometry}
\usepackage{fancyhdr}
\lhead{\bsc{Programmation Orientee Objet}}
\rhead{\bsc{TD6}}
\renewcommand{\headrulewidth}{1px}
\lfoot{ \bsc{Enseirb-Matmeca}}
\rfoot{ \bsc{Informatique - I2}}
\renewcommand{\footrulewidth}{1px}
\pagestyle{fancy}
\usepackage{wrapfig}
\usepackage{multicol}
\usepackage{textcomp}
\usepackage[T1]{fontenc}
\usepackage{setspace}
\usepackage{graphicx} 

%\usepackage[vlined,lined,boxed,french,longend]{algorithm2e}

\usepackage{graphicx}
\usepackage[french]{babel}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{mathrsfs}
\usepackage{xcolor}
\usepackage[utf8]{inputenc}
%%%%%%%%%%%%%%%% Variables %%%%%%%%%%%%%%%%
\def\projet{2}
\def\titre{Lot 2: Des nouveaux caractères d'usagers \\
  --------------------- \\Lien <<est-un>> ou <<a-un>>}
\def\groupe{2}
\def\equipe{piyovimoad}
\def\responsible{avilliermet}
\def\tandemi{ppocquetduhautjusse, vpomier}
\def\tandemii{ydubernet, mmegzari}

\begin{document}
%%%%%%%%%%%%%%%% Header %%%%%%%%%%%%%%%%
\noindent\begin{minipage}{\textwidth}
\vskip 0mm
\noindent
    { \begin{tabular}{p{7.5cm}}
        {\bfseries \sffamily
          Rapport du TD n°6 de l'équipe \equipe}
        \begin{center}{\itshape \titre}\end{center}
    \end{tabular}}
    \hfill 
    \fbox{\begin{tabular}{l}
        {~\hfill \bfseries \sffamily 23/10/12 \hspace{1.5mm} \hfill~} \\[2mm] 
        Coordinateur : \responsible \\
        Tandem1 : \tandemi \\
        Tandem2 : \tandemii
    \end{tabular}}
    \vskip 4mm ~

    \parbox{\textwidth}{\small \textit{Travail restant à la fin de la séance~:}
La partie 1 avait été traitée à la fin de la séance, la réalisation de la partie 2 restait à faire pour les 2 versions.


}
 \vskip 2mm ~

\parbox{\textwidth}{\small \textit{Remarques~:}
Pour la 2ème version du code (tandem2 pour cette séance) nous avions du retard accumulé depuis le td4 et avons donc perdu beaucoup de temps à finir les tds précédents avant de commencer celui-ci.
De plus, Mohammed ne pouvait être présent pendant la séance mais a travaillé après avec nous pour rattraper notre retard.
}

    \vskip 1mm ~
\end{minipage}




%%%%%%%%%%%%%%%% Main part %%%%%%%%%%%%%%%%
\section{Introduction}

La création de la classe PassagerAbstrait dans le td précédent a également créé les méthodes permettant de choisir une place lors de la montée dans le bus et de l'action à réaliser à chaque arrêt.
Notre but ici est de pouvoir modifier ces 2 méthodes pour différents types de passager et ce de manière indépendante.\\
Pour cela nous allons créer différentes actions de montée dans le bus ou à faire lors d'arrêts, encapsulées dans des objets. Il nous faudra alors rendre possible les différentes combinaisons de ces caractères.

\section{Quel lien choisir?}

Dans cette partie nous allons comparer et réfléchir à la meilleure solution entre l'utilisation d'un lien <<est-un>> et celle d'un lien <<a-un>> pour lier ces caractères à PassagerAbstrait.

\subsection{Avec un lien <<est-un>>}

Une première idée serait de réutiliser la même structure que précédement avec un lien d'héritage entre PassagerAbstrait et chaque type de passager comme le montre le diagramme suivant:\\
\begin{figure}[h!]
\begin{center}

\includegraphics[scale=0.5]{20classes.jpg}
\end{center}
\end{figure}

Cependant cela implique la création d'autant de classes concrètes que de combinaison de caractères possibles (ici 20) et donc beaucoup de duplication de code et de réécriture.
Cette solution n'est donc pas satisfaisante.

\subsection{Avec un lien <<a-un>>}

Une deuxième idée est donc d'utiliser plutôt des liens <<a-un>> pour une partie des caractères.
En effet, si une classe A possède un lien <<a-un>> avec une classe B, elle définit une ou plusieurs variables du type de la classe B. L'état d'une instance de A contient donc une référence à une instance de B.

En choisissant d'utiliser ce lien pour les caractères liés à la méthode ChoixChangerPlace() et en utilisant un lien <<est-un>> pour les autres, on ne créera que 9 classes concrètes. Cependant pour savoir dans PassagerAbstrait lequel des caractères utiliser lors d'un changement d'arrêt, on aura besoin de passer ceux-ci en paramètre d'une méthode. Il nous faut donc également créer un interface caractère ayant un lien <<a-un>> avec la classe PassagerAbstrait pour pouvoir spécifier ces caractères.\\
La méthode ChoixChangerPlace() a alors un nouveau prototype :\\
\texttt{public void choixChangerPlace(Bus b, int numeroArret, Passager p)}\\

Il n'est pas ici nécessaire d'instancier les objets, on veut uniquement pouvoir différencier les caractères qui ne sont que des attributs des Passagers. Un constructeur pour les cinq classes est donc inutile.

On aura alors le diagramme de classe suivant :

\begin{figure}[h!]
\begin{center}

\includegraphics[scale=0.5]{9classes.jpg}
\end{center}
\end{figure}

L'avantage de cette solution est la diminution de la duplication de code. En effet, la combinaison des différents caractères se fait de la même manière quels qu'ils soient et est donc écrite une seule fois.
De plus, le fait que des constructeurs ne soient pas nécessaires réduit la quantité de code écrite.

Pour utiliser davantage ces points et encore améliorer le code, on pourait utiliser la même méthode avec des liens <<a-un>> sur les caractères liés à la montée dans le bus.

\subsection{Boutez vos Neurones}

L'utilisation de l'héritage multiple  donnerait le diagramme de classe présenté ci-dessous.

\begin{figure}[h!]
\begin{center}

\includegraphics[scale=0.5]{heritagemultiple.jpg}
\end{center}
\end{figure}

Un type de passager utilise 2 des caractères dont il hérite.
Par exemple on a ici dessiné les liens utilisé par un passager standard.

Dans le cas précédent, on connaissait de manière dynamique l'état du passager. C'est à dire que l'on ne savait qu'au moment de l'instanciation quelle était sa combinaison de caractères.
Au contraire l'utilisation d'héritage multiple permet de traiter ce problème de manière statique.

\section{Réalisation du lien <<a-un>>}
Pour la mise en oeuvre de cette nouvelle architecture, le lien <<a-un>> utilisé sur quatres classes implique une instanciaton de celles-ci dans les autres classes.
Pour cela deux choix sont possibles :
\begin{itemize}
\item l'instanciation est faite dans le constructeur de chaque sous-classe
\item l'instance est passée en paramètre du constructeur des sous-classes et l'instanciation est alors faite par le client ou par une fabrique.\\
\end{itemize}

A ce stade du projet nous avons fait le choix d'appliquer la deuxième méthode pour notre version 1. En effet, nous avons eu du mal à saisir les conséquences de la première méthode et notament comment choisir les combinaisons de caractéristiques en appliquant cette méthode.

Nous avons donc obtenu le diagramme ci-dessous qui correspond à celui auquel nous nous attendions au dans la première partie. Cependant nous n'avons pas implémenté la totalité des caractères.

\begin{figure}[h!]
\begin{center}

\includegraphics[scale=0.5]{final.jpg}
\end{center}
\end{figure}

Nous n'avons pas implémenté la deuxième méthode du fait de notre incompréhension mais également de notre retard dans l'autre version du projet. En effet le td précédent n'a été terminé pour cette branche que tardivement.


\section{Conclusion}
Dans ce td nous avons pu travailler sur les différences entre les liens <<a-un>> et <<est-un>> et l'utilisation qu'on peut en faire. Cependant le retard de nos td précédent nous a ralenti et nous n'avons pas saisi toutes les subtilités des possibilités d'instanciation lors de l'utilsation de liens <<a-un>>.

\end{document}
